Replaces the framebuffer + grid composition logic in
`formatters/dashboard.ts` with an OpenTUI React app for the
Bun-compiled binary. The plain-text framebuffer is preserved
intact for the npm/Node distribution (where OpenTUI's Zig
bindings can't load), so existing tests + Node users see no
behavior change.

## What changed

- `src/lib/formatters/dashboard-app.tsx` (new) — React tree built
  from OpenTUI primitives (`<box>` / `<text>`). Lays out the
  dashboard header, then groups widgets by their grid `y` row
  and renders each row as a `flexDirection="row"` flex container
  with proportional widget widths (`(layout.w / 6) * termWidth`).
  Each widget is a rounded bordered box with the title in the
  border and content rendered via OpenTUI's flex layout — no more
  manual framebuffer composition.

- `src/lib/formatters/dashboard-tui.ts` (new) — Bridge between
  the React tree and a string. Uses OpenTUI's
  `createTestRenderer()` (from `@opentui/core/testing`) to mount
  the React tree off-screen, awaits a microtask for the
  reconciler's async commit phase, calls `renderOnce()`, and
  captures the rendered character grid via `captureCharFrame()`.
  Trailing blank lines are stripped so the output doesn't pad
  scrollback.

- `src/lib/formatters/dashboard.ts` — minor changes:
    - `DashboardViewData` gains an optional `rendered?: string`
      field (excluded from JSON output via `jsonExclude`) for
      stashing the OpenTUI-rendered string.
    - `renderContentLines()` is now exported so the OpenTUI app
      can reuse the per-widget content helpers (sparklines,
      big-number ASCII, table layout, markdown text) without
      duplicating them. ANSI escape codes from these helpers are
      stripped by the OpenTUI app before rendering — colors get
      reapplied via OpenTUI's `fg` prop at the row level.
    - `createDashboardViewRenderer` checks `data.rendered` first
      and uses it directly; otherwise falls through to the
      original `formatDashboardWithData` framebuffer path.

- `src/commands/dashboard/view.ts` — pre-renders the dashboard
  with OpenTUI inside the async `func()` (before yielding the
  `CommandOutput`) so the synchronous `HumanRenderer.render()`
  can just return the pre-baked string. Lazy-imports
  `dashboard-tui.js` via dynamic `import()` so its module-level
  `with { type: "file" }` resolution + heavy OpenTUI deps don't
  load when this command isn't being run — important because
  tests walk the Stricli route map (via `app.ts`) and would
  otherwise eagerly evaluate the OpenTUI side effects.
  Falls back to the plain-text formatter on import or render
  failure (Node distribution).

- `script/build.ts` + `script/bundle.ts` — extended sidecar
  cleanup to include `dashboard-app.tsx` alongside the existing
  `opentui-app.tsx`. The text-import-plugin copies both files
  into the output directory at build time; both are embedded
  into the Bun binary and unused on Node, so the local
  `dist*/` cleanup just keeps things tidy.

## Trade-offs

The OpenTUI `<text>` primitive doesn't honor embedded ANSI
escape codes — its content string is plain text. The plain-text
renderer's per-row mixed coloring (e.g. cyan label + magenta
sparkline + bold value on the same line) collapses to one
dominant color per row in the OpenTUI version. Tables get bold
headers + muted separators + plain body rows; sparkline rows
get accent purple; big-number rows get green. Loses some
granularity on tables/sparklines but the layout — which is what
OpenTUI is buying us — comes out clean.

The grid composition is approximate. The plain-text framebuffer
does true 2D composition where a tall widget can span multiple
row groups. The OpenTUI app groups widgets by their starting
`y` and renders each row group flush — widgets with non-uniform
`h` within a row render at their own height but don't overlap
the next row. Most dashboards we've seen are uniform-height per
row, so the approximation lands clean.

## Verification

- `bun run typecheck` (clean)
- `bun x ultracite check` (1 pre-existing warning, no new ones)
- `bun test --isolate test/lib/init/ test/lib/formatters/dashboard*.test.ts test/commands/dashboard` (458 pass)
- `SENTRY_CLIENT_ID=test bun run build` (binary 118.29 MB,
  unchanged from before)
- `SENTRY_CLIENT_ID=test bun run bundle` (npm 3.21 MB,
  unchanged)
- `./dist-bin/sentry-linux-x64 dashboard view --help` (renders
  cleanly)
- Visual smoke test rendering a 3-widget dashboard confirms
  bordered widget boxes, vertical bar chart, big-number, and
  table all lay out correctly with OpenTUI's flex engine.

## Tests added

- `test/lib/formatters/dashboard-tui.test.ts` — 10 coarse
  end-to-end tests asserting the renderer produces a
  non-empty string with the dashboard title, period badge,
  environment badge, widget titles, box-drawing characters,
  trailing-blank-line trimming, and graceful handling of
  empty widget lists, orphan widgets, and error widgets.

… runners

Two CI-only failures from PR #887:

1. Biome formatter wanted the sidecar-cleanup for-loop on a single line.
   Auto-fixed via `bun x biome format --write script/bundle.ts`.

2. Tests fail in CI with an empty captured frame because React's
   reconciler commit + OpenTUI's layout pass don't fully complete after
   one `setTimeout(0)` + `renderOnce()` on slower CI runners. Render
   twice with a microtask wait between — the first pass flushes pending
   layout effects, the second captures the laid-out frame. Locally a
   single pass works because event-loop turns are faster.

Converts the static OpenTUI dashboard renderer into a live
interactive TUI on the Bun binary. The npm/Node distribution
falls back to the existing plain-text framebuffer, unchanged.

Keybindings:

- Tab / Shift+Tab / arrows  Cycle widget focus
- Enter                     Drill into focused widget
- Esc                       Back out one layer (drilldown → help → quit)
- t                         Cycle time period (1h → 24h → 7d → 30d → 90d)
- r                         Refresh now
- R                         Toggle auto-refresh
- o                         Open dashboard in browser
- ?                         Toggle keybindings overlay
- q / Ctrl+C                Quit

Implementation:

- `dashboard-store.ts` — external state store with action
  dispatcher slot. Owns focus index, drilldown / help overlay
  flags, current period, auto-refresh enabled, fetching state,
  fetch error. Pure mutators with idempotency invariants.

- `dashboard-runtime.ts` — mounts a long-lived
  `createCliRenderer({ exitOnCtrlC: false, screenMode:
  "alternate-screen" })`. Services dispatched actions:
  `refresh` and `cycle-period` re-fetch via the caller-supplied
  `fetch` callback; `toggle-auto-refresh` flips the timer;
  `open-in-browser` calls `openBrowser` directly (NOT
  `openInBrowser`, which would write "Opening in browser…" to
  stdout and corrupt the alternate-screen TUI); `quit` resolves
  the runtime promise so the caller returns to the shell.
  Cleanup order: detach dispatcher → stop timer → unmount React
  tree → destroy renderer (releases alt-screen + raw mode last).

- `dashboard-app.tsx` — App now subscribes via
  `useSyncExternalStore`, has a `useKeyboard` hook that
  delegates to extracted top-level handler functions
  (`handleKey`, `handleEscape`, `handleHelpKey`,
  `handleDrilldownKey`, `handleGridKey`). Renders a Drilldown
  view that takes over the screen for the focused widget, a
  HelpOverlay that lists keybindings, and a StatusBar pinned
  to the bottom showing the current shortcut hints.

- `dashboard-tui.ts` (static path) — unchanged behavior;
  constructs a default-state store and passes it to the same
  App component the interactive runtime uses. Existing 10
  static-render tests still pass.

- `view.ts` — adds `isInteractiveContext()` (TTY both ends +
  non-JSON + Bun runtime) and `tryRunInteractive()` which
  lazy-imports `dashboard-runtime.js` (matches the existing
  `tryPreRenderTui` lazy-import pattern). Falls through to the
  existing static path on import failure or non-interactive
  context. The `--refresh N` flag now means "start interactive
  with auto-refresh ON at N seconds" rather than a static
  polling loop; legacy non-interactive consumers (CI / piped /
  JSON) still get the polling loop.

Bun-binary only — same gating as the static path. Non-Bun
runtimes externalize OpenTUI and the lazy import resolves to
"Cannot find module", caught and falling through to plain
text.